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Title 

Method for authenticating a user to a service of a service provider 

5 Technical field of the invention 

The present invention relates to the field of authentication, especially to a 
method for authenticating a user to a service of a service provider. 

1 0 Background of the invention 

Many electronically available services like web sites on the Internet or e- 
commerce require a user identification and authentication for a number of 
purposes like offering access to confidential information or services or 

15 resources, e.g. web-based email access, or online banking, like offering 

personalized services, adapted to a user profile, like data mining, i.e. drawing 
conclusions from the interactions of a multitude of users with the service, e.g. 
for creating profiles of a user's behavior as a consumer, or like verifying the 
user's credit worthiness in e-commerce applications e.g. by making sure that 

20 the user has always paid his bills. User identification and authentication can be 
also required for granting access to other forms of services like access to 
physical units like doors of vehicle or a company building or a steering wheel. 

Identification means the specification of an identity that unambiguously 
25 identifies a certain user or group of users. The specified identity may or may not 
be traceable to a particular person or group of persons, i.e. the identity could be 
the user's name in clear text, but it could also be a randomly chosen login 
name. The only requirement is that only a single person or a person from a 
specific group of persons, in the case of a group login, can have registered 
30 under that particular user identity based on which the identification of the 
registered user is possible. An example is e.g. a login name of the user for 
accessing a service of a service provider. Authentication is defined as the 
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verification of an identity, e.g. the verification that a user presenting a certain 
identity is actually the same user who has initially registered under that same 
identity. 

5 Authentication is done by verifying user credentials. There are essentially three 
types of user credentials. First of all, something the user possesses, e.g. a key, 
a smart card, a passport, a company identity card, etc., secondly something the 
user knows, e.g. a password, a personal identification number (PIN), his 
mother's maiden name, etc., and thirdly bodily features of the user, e.g. iris 
10 patterns, voice, fingerprint, facial features, handwriting, etc. 

A user authentication may consist of the verification of a single or of multiple 
types of credentials, e.g. password only vs. possession of a company ID in 
combination with knowledge of a PIN code. A user identity, e.g. a name of the 

15 user, is used in an identification step to relate user credentials collected from 
the user in the authentication to user credentials associated to the user identity 
as registered. By verifying that the collected user credentials and the registered 
user credentials match, the verification of the user identity and thus the 
authentication can be accomplished. Thus authentication typically comprises an 

20 identification of an entity for that authentication is requested as prerequisite and 
a registration of the user is typically necessary for the authentication. 

In the past, each service provider typically performed its own user identification 
and authentication, e.g. most commonly via a username and password, 

25 possibly using a secure transport protocol, and kept track of its own user profile 
database. The drawback for the user is that he typically has to remember 
different combinations of user identities and passwords, or more general 
different combinations of user identities and credentials, for different service 
providers which is inconvenient and in most cases not very secure when the 

30 user notes his different user identities and corresponding respective passwords 
(credentials). Security is further compromised if the user uses same or similar 
combinations for different service providers. The drawback for a service 
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provider is that it has to maintain own databases and has to execute all steps 
for authentication by its own. In addition, service-provider-owned authentication 
is typically based on a single or a very limited number of user credential types 
due to technical and economical reasons, because setting up the appropriate 
5 infrastructure for the collection and processing of user credentials of different 
types is costly, which is a severe barrier for the introduction of modern 
authentication methods like methods based on biometrics or based on smart 
cards like a Subscriber Identity Module (SIM) card in a mobile phone. 

1 0 Recently, a number of technologies have emerged, e.g. Microsoft ® Passport, 
see e.g. Microsoft Passport Technical White Paper, March 2001, published on 
http://www.passport.com, that aim at separating the authentication from the 
actual service. In this case, an "Identity Provider" ("IdP") is responsible for user 
registration and, whenever the user wants to access a service, for user 

15 authentication. User registration and user authentication can be implemented in 
a single entity or can be separated. The provider of the actual service ("Service 
Provider", "SP") may or may not be identical with the identity provider. An 
identity provider could act as a provider of some services itself and in addition 
provide identity services towards external service providers. In Microsoft ® 

20 Passport, user authentication is always done via a username/password 
mechanism, transported via SSL, without any restrictions on the password 
change interval for accessing to any kind of service registered to Microsoft ® 
Passport. 



25 The separation of the identity provider and service provider functionalities has a 
number of advantages: The service provider not necessarily has to handle its 
own user registration and authentication, but can "outsource" these to the 
identity provider. More importantly, however, the user can avail of a single, 
consistent log-in procedure across different services. As mentioned, today users 

30 either need to remember and/or possess separate authentication credentials for 
each service provider, or they re-use credentials such as passwords which, of 
course, compromises the security. For example, an attacker could eavesdrop 
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an unencrypted password the user enters at a web portal and then use it to try 
to get access to the user's online bank account with the same password. 

However, the known identity provider solution Microsoft ® Passport does not 
5 distinguish between different security requirements for different services or 
service providers. The security requirement by a service provider can strongly 
depend on the purposes for which the authentication is needed. For simply 
providing a personalized web portal, a lower security level will typically be 
sufficient than for online access to a bank account or for authorizing a major 

1 0 monetary transaction. Rather, Microsoft ® Passport considers authentication a 
binary decision like being authenticated or being not authenticated based on a 
single credential type and assumes that the static authentication mechanism 
based on the username - password combination is known to both the identity 
provider and the service provider, and has been - explicitly or implicitly - 

1 5 agreed upon beforehand. This obviously has a number of disadvantages, 
including first of all the inability to cope with different types of security 
requirements for different services/resources and the inability to cope with 
changes in the security requirements over time. If a Passport-like identity 
provider ever decides to change the authentication process, this would need to 

20 be communicated to each service provider separately using out-of-band means, 
or the service provider simply would have to hope that any changes that the 
identity provider applies, are "reasonable". 

WO 01/1 1450 discloses a system architecture and a method for a single sign on 
25 authentication to multiple information resources. The security architecture 
associates trust-level requirements with information resources and 
authentication schemes based on passwords, certificates, biometric techniques 
and smart cards are associated with the trust levels. Upon receipt of a request 
for access to an information resource without prior authentication to a sufficient 
30 trust level, a gatekeeper interposed between the client entity and the 

information resources uses a credential gathering service for obtaining a login 
credential for the client entity in accordance with a mapping rule establishing a 
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correspondence between the sufficient trust level and a set of suitable 
credential types. 

The system described in WO 01/1 1450 A1 has a number of limitations. First of 
5 all, it relies on associations between the information resources and trust levels 
and mapping rules between the trust levels and the credential types used for 
the authentication, both, requiring a priori knowledge and prior agreement on 
the associations and the mapping rules between the entity providing identity 
provider functionality and the information resource. Furthermore, all information 

10 resources that are associated to the same trust level are handled in the same 
way. This becomes especially a problem whenever an identity provider decides 
to change an association and/or a mapping rule, because not all of the 
information resources (or providers of the respective information resources) 
being affected by the change may find the change acceptable e.g. due to 

15 security, technical or business-related reasons. Thus, in the end not the 

provider of the information resource or the information resource itself but the 
identity provider determines the authentication process, i.e. determines which 
particular credentials are to be used for a particular authentication. 

20 However, these kinds of policy decisions taken by an identity provider are not 
acceptable for many service providers. An updating of associations or mapping 
rules may thus result in conflicts with the service providers. Static or pre-defined 
associations or mapping rules are not flexible enough to serve the requirements 
of the entities involved. In addition, it is rather complicated to express all 

25 possible combinations of authentication schemes and credential types by 
predefined associations or mapping rules for satisfying the various security 
requirements for all service providers and type of services especially in the view 
of the increasing amount and variety of authentication methods and the, 
sometimes rapidly, changing requirements of the service providers. Due to the 

30 inherent inflexibility of predefined associations or mapping rules for such a large 
variety of possibilities, cumbersome association or mapping rule updating 
operations, if ever possible, have to be executed before an authentication 
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according to a new security requirement can be made. This inflexibility is 
especially a drawback in ad-hoc situations, e.g. when access to a, e.g. newly 
introduced, service being not associated to any or valid trust level is requested. 
A further limitation is that all information flow including requests and responses 
5 during a session between the client and the information resource accessed 
goes through the gatekeeper as an in-path component. However, using an 
identity provider as an in-path component for the complete information flow 
between a user client and the service provider unnecessarily increases the load 
for the identity provider. 

10 

Another limitation common for Microsoft ® Passport and WO 01/1 1450 A1 is 
that a single identity provider is used for authentication purposes. This 
restriction forces users and service providers to trust a single identity provider. 
However, a centralized authentication instance is often not acceptable for users 
15 and service providers because of privacy, trust, business, or cost reasons. For 
example, a user may not want user-related information like different type of 
credentials to be gathered at a single identity provider in order to prevent 
unnecessary data aggregation or even fraud. 

20 Summary of the invention 

It is an object of the present invention to provide methods, devices, and 
computer programs that provide an authentication of a user to a service of a 
service provider in more secure and flexible way. 

25 

This object is achieved by the methods as described in claims 1 and 9. 
Furthermore, the invention is embodied in devices as described in claims 15, 
21 , 27, and 34 and computer programs as described in claims 36 and 37. 
Advantageous embodiments are described in the further claims. 

30 

A method for an authentication of a user to a service of a service provider is 
disclosed. 
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The method can start by requesting access for the user to the service of the 
service provider. The request may be sent from a device of the user to the 
service provider triggering the service provider to proceed with the following 
5 steps. Alternatively, the request may be pre-configured and reaches the service 
provider e.g. at predefined times or intervals. 

Triggered by the request for access, the service provider selects one or more 
authentication security profiles for specifying an authentication security 
1 0 requirement for the authentication of the user to the service. 

The method proceeds by sending an indication of the one or more selected 
authentication security profiles and a user identity identifying the user to an 
identity provider for requesting the authentication of the user by the identity 

15 provider, i.e. the service provider sends from its associated device or an device 
being, e.g. remotely, accessible by the service provider the one or more 
selected authentication security profiles as one form of an indication for 
indicating to the identity provider the authentication security requirement in the 
form of one or more authentication security profiles based on one of them the 

20 authentication is to be executed. In addition, the user identity is sent to the 
identity provider for the purpose of an identification of the user for the 
authentication step. 

Next, based on the user identity and one of the one or more selected 
25 authentication security profiles, the user is authenticated by the identity 

provider. Authentication can be accomplished by identifying the user, e.g. as 
previously registered to the identity provider, and verifying the user on base of 
the user identity according to the one authentication security profile. 

30 Finally, the information about a result of the authentication by the identity 
provider can be send to the service provider. In particular, an assertion 
indicating the authentication of the user is sent to the service provider, e.g. for 
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indicating that the authentication of the user has been accomplished according 
to the authentication security requirement as specified by the authentication 
security profile by the service provider. Depending on the implementation or use 
case, the assertion can e.g. specify the one authentication profile used for 
5 authentication or simply indicate "authentication successful". Other 
implementations for the assertion are possible. 

The method improves the authentication of a user to a service of a service 
provider and makes the method especially very secure for the service provider, 

10 because the service provider and not the identity provider determines in the end 
the security requirement to be fulfilled by the identity provider for the 
authentication of the user according to one of the authentication security profiles 
as selected by the service provider. The method is also more secure for the 
identity provider because it can be clearly and on-the-fly instructed which 

1 5 authentication requirement of the service provider currently applies and has to 
be fulfilled for the current authentication of the user. The authentication security 
requirement of the service provider may change. In this case, the service 
provider may immediately adapt to its changed security requirement by 
selecting another authentication security profile thus making the method more 

20 secure but also very flexible for the service provider. Thus especially in ad-hoc 
scenarios but also further situations and environments with changing 
authentication security requirements for the service provider, the service 
provider can act flexibly and can immediately specify and communicate to the 
identity provider its changed authentication requirement by one or more 

25 selected authentication profiles when requesting authentication from the identity 
provider. Furthermore, the method does not require the service provider to 
make usage of a specific single identity provider. Instead, any identity provider 
can be used for the authentication. In addition, it is not required to have the 
identity provider as in-path component interposed between the service provider 

30 and the client. 
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According to a preferred embodiment, the one or more authentication security 
profiles comprise at least one security attribute for, e.g. more precisely, 
specifying the authentication security requirement. The service provider can 
assemble one or more authentication security profiles by specifying security 
5 attributes. By doing its own specification, the service provider can tailor an 
authentication security profile exactly to its security requirement. The service 
provider may, alternatively or in addition, select a pre-defined authentication 
security profile comprising one or more security attributes arranged in a pre- 
defined manner. Authentication capabilities of the identity provider and/or the 

10 user may be taking into consideration when specifying and/or selecting an 
authentication security profile based on one or more security attributes. 
Examples for a security attribute are a specification describing an item from a 
group of a credential, a transport layer security, a network security, a link layer 
security, timing information, a policy, a fraud detection measure, a liability 

1 5 and/or guarantee and other security features. The security attribute can 
comprise a specification of a type, e.g. a credential type like password or 
biometrics, and a specification of a value associated to a particular type, e.g. a 
password length associated to a password or a fingerprint of certain resolution 
associated to biometrics. Using security attributes, the identity provider can be 

20 precisely instructed by the service provider based on which security features 
according to the requirements of the service provider the authentication of the 
user has to be executed by the identity provider. 

According to another preferred embodiment, the service provider selects the 
25 one or more authentication security profiles from a group of one or more 

security profiles that are indicated to be supported by the identity provider for 
the authentication. Selecting the one or more authentication security profiles 
from a group of one or more supported authentication security profiles 
increases the probability for a successful authentication. 



According to a another preferred embodiment, the service provider receives an 
indication for the group of the one or more supported security profiles from the 
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identity provider, e.g. by sending a list of supported authentication security 
profiles. The indication can be also an URI pointing to a server from which the 
group can be obtained, e.g. downloaded, by the service provider. Other ways of 
indications are possible. Preferably, the indication for the group or the group 
5 itself as one form of an indication is sent to the service provider when changes 
in the authentication capabilities of the identity provider occur, e.g. when the 
identity provider discards a certain security attribute like a credential type and/or 
credential value from being supported, e.g. password length shorter than 4 
characters being no longer supported, or if the identity provider offer a newly 
1 0 introduced credential type or value, e.g. finger prints being supported as from 
today. 

According to another preferred embodiment, said one authentication security 
profile based on which the authentication is executed is selected by the identity 

1 5 provider from the one or more selected authentication security profiles. By doing 
so, the identity provider can avoid to ask the service provider based on which 
one of the selected authentication security profiles the authentication is to be 
executed. Instead, the identity provider can assume that all of the selected and 
indicated authentication security profiles meet the authentication security 

20 requirement of the service provider and can select the one that fits best, e.g., to 
the needs or capabilities of the identity provider and/or of the user that has to 
authenticated. Furthermore, the interaction between the service provider and 
the identity provider for negotiating the authentication security profile based on 
which the authentication of the user is actually executed can be minimized and 

25 thus the speed and probability of a successful authentication increased. 

According to another preferred embodiment, the one or more selected 
authentication security profiles can be related by one or more relations to one or 
more further authentication security profiles. Each of these relations express an 
30 ordering of the one or more selected authentication security profiles to the one 
or more further authentication security profiles regarding an authentication 
security strength. Examples for relations are directed edges expressing e.g. a 
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stronger than or equally strong as relation between two authentication security 
profiles. Selected authentication security profiles may also be related with each 
other. Based on the relation of the one or more selected authentication security 
profiles to the one or more further authentication security profiles, i.e. the 
5 information about the ensemble of the selected and the further authentication 
profiles and the respective relations, the step of authenticating the user based 
on one of the one or more selected authentication security profiles can be 
executed by selecting by the identity provider one of the one or more further 
authentication security profiles being related equally strong or stronger 

1 0 regarding the authentication security strength compared to the one or more 
selected authentication security profiles and authenticating the user based on 
the further authentication security profile as selected by the identity provider. 
Thus, the variety and number of authentication security profiles meeting the 
authentication security requirement of the service provider is enlarged. From the 

1 5 enlarged variety and number of the authentication security profiles the identity 
provider can flexibly select one authentication profile for the authentication, e.g. 
one that fits best to certain capabilities as explained before, thus increasing the 
possibility for a successful authentication and the speed of the authentication. 

20 According to another preferred embodiment, the service provider can specify 
the one or more relations to the one or more further authentication security 
profiles and the service provider can send an indication of the one or more 
relations to the one or more further authentication security profiles to the identity 
provider. By doing so, the relations between the one or more selected and the 

25 one or more further authentication security profiles more precisely reflect the 
authentication security requirement of the service provider which can lead to a 
faster authentication with less interaction for the negotiation of an authentication 
security profile to be actually used for the authentication. 

30 According to another preferred embodiment, the assertion is supplemented by 
an indication of the authentication security profile based on which the 
authentication is executed and the indicated authentication security profile is 
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checked by the service provider for acceptance. Providing the service provider 
with information about the authentication security profile based on which the 
authentication is executed increases further the security for the service provider 
and provides the service provider with the possibility to e.g. check if the 
5 authentication security profile actually been used for the authentication satisfies 
its current authentication security requirement. 

A method for an authentication of a user to a service of a service provider is 
disclosed. The method comprises the steps of requesting access for the user to 

1 0 the service of the service provider, sending a user identity identifying the user to 
an identity provider for requesting the authentication of the user by the identity 
provider, authenticating the user based on the user identity and an 
authentication security profile, sending an assertion indicating the authentication 
of the user to the service provider, the assertion being supplemented by an 

1 5 indication of the authentication security profile, and checking by the service 
provider the indicated authentication security profile for acceptance. 

Here, the service provider does not provide the identity provider with its security 
authentication requirement beforehand the authentication, which can be 

20 advantageous for some implementations. However, the service provider is still 
capable to verify that the authentication of the user to the service matches to 
the authentication security requirements of the service provider by checking the 
indicated authentication security profile based on which the authentication of the 
user is executed versus the security requirement of the service provider. 

25 Furthermore, flexibility for the identity provider can be increased due to the fact 
that an authentication based on any authentication security profile supported by 
the identity provider can be used for the authentication, preferably matched to 
the authentication capabilities of the user, if a credential verification is 
necessary. In the end, it is the service provider that is empowered to decide if a 

30 user is or is not sufficiently authenticated. 
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Both methods can further comprise the step of receiving at the service provider 
from a user device the user identity and a reference to the identity provider in 
response to a request for authentication sent from the service provider to the 
user device. This interaction with the user device is very common and can ease 
5 the implementation. 

Based on the received assertion, the access to the service based on the 
assertion can be granted. Alternatively, access to the service can be granted 
based on the assertion and based on the check for acceptance, e.g. by 
10 checking if the indicated authentication security profile matches to the 

authentication security requirement of the service provider thus increasing the 
security of the authentication especially for the service provider. 

According to another preferred embodiment, the method can comprise a step of 
15 an authentication upgrade. The authentication upgrade can be executed by 
performing a further authentication based on the further authentication security 
profile. The selection and the further authentication can be executed according 
to any of the steps relating to the selection and the authentication of the method 
for authenticating the user to the service of the service provider as described 
20 before, e.g. the service provider may select one or more authentication security 
profiles and send these to the identity provider which selects one of them for 
authentication of the user. The identity provider may select one authentication 
security profile based on relations and may indicate an selected authentication 
security profile based on which the authentication is executed to the service 
25 provider, which can e.g. check the indicated authentication security profile if it 
matches to its authentication security requirement for the authentication. The 
upgrade functionality can provide the user and the service provider to continue 
a session if a service with a stronger authentication security requirement is to be 
accessed. 



According to another preferred embodiment, the authentication upgrade can 
comprise a change to a further identity provider for executing the further 
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authentication of the user based on the further authentication security profile, 
thus e.g. enabling to continue the service session in case that the previous 
identity provider cannot support the further authentication profile according to 
the stronger authentication security requirement of the service provider. 

5 

The invention is further embodied in devices. In the following, a device 
associated to a service provider and a device associated to an identity provider 
are described. 

10 A device associated to a service provider is disclosed. The device associated to 
the service provider comprises a receiving unit for receiving messages, a 
transmitting unit for sending messages, and a processing unit for processing 
messages and information. The device associated to the service provider can 
be adapted to receive a request for access of a user to a service of the service 

1 5 provider, to select one or more authentication security profiles for specifying an 
authentication security requirement for an authentication of the user to the 
service, to send an indication of the one or more selected authentication 
security profiles and a user identity identifying the user to an identity provider for 
requesting the authentication of the user by the identity provider, and to receive 

20 an assertion indicating the authentication of the user by the identity provider. 

According to a preferred embodiment, the device associated to the service 
provider can be adapted to select the one or more authentication security 
profiles comprising at least one security attribute for specifying the 
25 authentication security requirement. 

According to another preferred embodiment, the device associated to the 
service provider can be adapted to select the one or more authentication 
security profiles from a group of security profiles that are indicated to be 
30 supported by the identity provider for the authentication. 



WO 03/100544 



15 



PCT/EP03/05421 



According to another preferred embodiment, the device associated to the 
service provider can be adapted to receive an indication for the group of the one 
or more supported security profiles from the identity provider. 

5 According to another preferred embodiment, the device associated to the 
service provider can be adapted to relate the one or more selected 
authentication security profiles to one or more further authentication security 
profiles, each relation expressing an ordering of the one or more selected 
authentication security profiles to the one or more further authentication security 
10 profiles regarding an authentication security strength, and the device can be 
further adapted to send at least the one or more relations to the one or more 
further authentication security profiles being related equally strong or stronger 
regarding the authentication strength to the identity provider for the 
authentication. 

15 

According to another preferred embodiment, the device associated to the 
service provider can adapted to receive an indication of the authentication 
security profile based on which the authentication of the user is executed by the 
identity provider and the device is further adapted to check the indicated 
20 authentication security profile for acceptance. 

Alternatively or in addition, the device associated to the service provider can be 
adapted to receive a request for access of a user to a service of the service 
provider, to send a user identity identifying the user to an identity provider for 
25 requesting an authentication of the user by the identity provider, to receive an 
assertion indicating the authentication of the user from the identity provider, the 
assertion being supplemented by an indication of the authentication security 
profile, to check the indicated authentication security profile for acceptance. 

30 According to another preferred embodiment, the device associated to the 

service provider can be adapted to receive the user identity and a reference to 
the identity provider from a user device in response to a request for 
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authentication sent from the device associated to the service provider to the 
user device. 

According to another preferred embodiment, the device associated to the 
5 service provider can be adapted to grant access to the service based on the 
assertion. 

According to another preferred embodiment, the device associated to the 
service provider can be adapted to grant access to the service based on the 
1 0 assertion and the check for acceptance. 

According to another preferred embodiment, the device associated to the 
service provider can be adapted to execute an authentication upgrade based on 
a further authentication based on a further authentication security profile. 

15 

According to another preferred embodiment, the device associated to the 
service provider, can be adapted to change for the authentication upgrade to a 
further identity provider for executing the further authentication. 

20 A device associated to an identity provider is disclosed. The device associated 
to the identity provider comprises a receiving unit for receiving messages, a 
transmitting unit for sending messages, and a processing unit for processing 
messages and information. The device associated to the identity provider can 
be adapted to receive a request for an authentication of a user. The request 

25 comprises a user identity identifying the user to the identity provider, e.g. to the 
device associated to the identity provider, and an indication for one or more 
authentication security profiles specifying an authentication security requirement 
of the service provider for the authentication of the user to a service of the 
service provider. The device associated to the identity provider can be further 

30 adapted to authenticate the user based on the user identity and one of the one 
or more authentication security profiles, and to send an assertion indicating to 
the service provider the authentication of the user. 
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According to a preferred embodiment, the device associated to the identity 
provider can be adapted to authenticate the user based on at least one security 
attribute comprised in the one authentication security profile based on which the 
5 authentication is executed. 

According to another preferred embodiment, the device associated to the 
identity provider can be adapted to send an indication for a group of one or 
more security profiles that are supported for the authentication by the identity 
1 0 provider to the service provider. 

According to another preferred embodiment, the device associated to the 
identity provider can be adapted to select said one authentication security 
profile based on which the authentication is executed from the one or more 
15 authentication security profiles. 

One or more authentication security profiles can be related by one or more 
relations to one or more further authentication security profiles. Each of the one 
or more relations express an ordering of the one or more authentication security 

20 profiles to the one or more further authentication security profiles regarding an 
authentication strength. The device associated to the identity provider can be 
adapted to execute the authentication of the user by selecting one of the one or 
more further authentication profiles being related equally strong or stronger 
regarding the authentication security strength compared to the one or more 

25 authentication security profiles and by authenticating the user based on the 
selected further authentication security profile. 

According to another preferred embodiment, the device associated to the 
identity provider can be adapted to receive an indication for the one or more 
30 relations to the one or more further authentication security profiles from the 
service provider. 
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According to another preferred embodiment, the device associated to the 
identity provider can be adapted to supplement the assertion with an indication 
of the authentication security profile based on which the authentication is 
executed. 

5 

Alternatively or in addition, the device associated to the identity provider can be 
adapted to receive a request for an authentication of a user. The request 
comprises a user identity identifying the user to the identity provider, e.g. the 
device of the identity provider. The device associated to the identity provider 
10 can be adapted to authenticate the user based on the user identity and an 

authentication security profile and to send an assertion indicating to the service 
provider the authentication of the user. The assertion is supplemented by an 
indication of the authentication security profile based on which the 
authentication of the user is executed. 

15 

According to another preferred embodiment, the device associated to the 
identity provider can be adapted to execute an authentication upgrade being 
based on a further authentication based on a further authentication security 
profile. 

20 

The invention is further embodied in one or more computer programs. The one 
or more computer programs comprise portions of software codes loadable into 
devices for executing any of the steps of the authentication method. The one or 
more computer programs can be stored on a computer readable medium. The 
25 computer-readable medium can be a permanent or rewritable memory within a 
device or located externally. The computer program can be also transferred to a 
device for example via a cable or a wireless link as a sequence of signals. 

In particular a computer program loadable into a device associated with a 
30 service provider is disclosed. The computer program comprises code adapted 
to process a request for access of a user to a service of the service provider, to 
select one or more authentication security profiles for specifying an 
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authentication security requirement for an authentication of the user to the 
service, to initiate a sending of an indication of the one or more selected 
authentication security profiles and a user identity identifying the user to an 
identity provider for requesting authentication of the user by the identity 
5 provider, and to process an assertion indicating the authentication of the user 
by the identity provider. 

Alternatively, the computer program may be in a format that the software 
portions relating to the selection of the one or more authentication security 

1 0 profiles and the sending of the indication of the one or more authentication 
security profile to the identity provider are not included or skipped and instead 
or in addition, the computer program comprises code adapted to check an 
indicated authentication security profile based on which the authentication of the 
user is executed for acceptance, the indicated authentication profile being 

15 entered into the computer program in conjunction with the assertion. 

Furthermore, a computer program being loadable into a device associated to an 
identity provider is disclosed. The computer program comprises code adapted 
to process a request for an authentication of a user, the request comprising a 

20 user identity identifying the user to the identity provider and an indication for one 
or more authentication security profiles specifying an authentication security 
requirement of the service provider for the authentication of the user to a 
service of the service provider, to execute an authentication of the user based 
on the user identity and one of the one or more authentication security profiles 

25 received from the service provider, and to initiate a sending of an assertion 
indicating to the service provider the authentication of the user. 

Further ways of implementing the method according to the invention by 
computer programs are possible. Especially, the computer programs may 
30 implement any embodiments of the method as described. 
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In the following, detailed embodiments of the present invention are described 
with reference to the figures. 

Brief description of the drawings 

5 

Fig. 1a shows an example for an authentication security profile with 
attributes; 

Fig. 1 b shows an example for authentication security profiles and their 
10 ordering with regard to authentication security strength; 

Fig. 2 shows examples for mappings between numeric attribute values 

and authentication security strength; 

1 5 Fig. 3 shows a first exemplary message flow for authentication; 

Fig. 4 shows a second exemplary message flow for authentication; 

Fig. 5 shows a third exemplary message flow for authentication; 

20 

Fig. 6 shows a fourth exemplary message flow for authentication; 

Fig. 7 shows a fifth exemplary message for authentication; 

25 Fig. 8 shows a sixth exemplary message flow for authentication; 

Fig. 9 shows a seventh exemplary message flow for authentication; 

Fig. 1 0 shows a first exemplary message flow for an authentication 
30 upgrade; 
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Fig. 11 



shows a second exemplary message flow for an authentication 
upgrade; 



Fig. 12 



shows an example for a device for implementing the method; 



5 



Fig. 13 



shows a first example for devices and links between the devices 
for carrying out the method; 



10 



Fig. 14 



shows a second example for devices and links between the 
devices for carrying out the method; 



Fig. 15 



shows a third example for devices and links between the devices 
for carrying out the method. 



1 5 Detailed description of the invention 

The authentication method can be composed of the three following elements: 
Firstly, a data structure for describing one or more Authentication Security 
Profiles (ASProfs) and possible relations between ASProfs as a structured, 

20 extensible and machine-readable set. For describing the data structure, a 

directed graph may be used to express the relation between different ASProfs, 
e.g. "is stronger than or equally strong as" (>). In this graph, each node is an 
ASProf, and each directed edge expresses a relation between two ASProfs. 
Secondly, a method for agreeing on an ASProf to be used for authentication of 

25 a user to a service of a service provider. The service provider can send one or 
more required ASProfs in the sense of a "wish list" to an identity provider which, 
in turn, decides whether or not it can comply and may make alternative 
suggestions for one or more ASProfs to be used. Using references and 
updates, as opposed to sending the full ASProfs back and forth, can reduce 

30 exchanged data. A further identity provider may be contacted for authentication 
if the first identity provider cannot meet the requirements of the service provider. 
Thirdly, a method for upgrading an ASProf during a session; upgrading an 
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ASProf during a session involves re-negotiating the ASProf and may also 
require a new validation of user credentials. If the identity provider cannot meet 
the upgraded ASProf, the service provider may contact an alternative identity 
provider for the upgrade. 

5 

The level of certainty that a user who claims to have identity X actually is the 
user associated with this identity, can be seen on a continuous scale and 
depends on a number of factors, including, but not limited to: 

one or more types of user credentials verified for authentication, e.g. 
10 a password may be considered less secure than a company ID in 

combination with a PIN code; 

transport, network and link layer security features used when 
communicating authentication information (e.g. passwords) between 
client and server, e.g. TLS, IPsec; 

1 5 - time of the most recent authentication, e.g. a PIN that has been 

entered ten seconds ago is typically more secure than a PIN that has 
been entered three days ago since an attacker could have gained 
unauthorized access to the client device in the meantime; 
length and complexity of the user credentials, e.g. length of pass- 

20 word or PIN, password containing letters only vs. password 

containing at least two digits and at least two special characters, 
length of a secret key, etc.; 

policies with respect to the handling of secret user credentials, e.g. 
how often does a password have to be changed, after how many 
25 changes may an old password be reused, how does the identity 

provider protect the confidentiality and integrity of secret user 
credential data; 

policies with respect to key handling if a public key infrastructure (PKI) 
is used, e.g. how is certificate revocation handled, which root 
30 certificates are trusted, etc.; 
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measures taken to detect fraud, as well as the procedures for 
revocation of credentials and time needed for revocation in the case 
of fraud detection; 

liability / guarantees provided by the identity provider to the service 
5 provider for the case of fraud; 

policies with respect to verifying the user's "real" identity upon 
registration to the identity provider, e.g. entering a name and personal 
data on a web page may be considered as less secure than 
verification of passport. 

10 

In the this document, the aggregation of these and other attributes influencing 
the certainty level of a user authentication is referred to as an "Authentication 
Security Profile" ("ASProf ). 

1 5 The ASProf is described as a set of attributes, e.g. by those attributes given 

above, with or without attribute values. For example, an empty or default ASProf 
may have attributes without having attribute values assigned to the attributes. 
The ASProf can be conceived to comprise policies describing processes by 
which authentication credentials will be handled, renewed, revoked, etc. The 

20 ASProf description is preferably changeable, extensible and machine-readable. 
Preferably the extensible Markup Language (XML) is used as an underlying 
meta-language. Extensibility is important because an ASProf is typically no 
closed set of data but may need to be adapted to emerging authentication 
technologies like biometrics and to novel security technologies, e.g. 

25 cryptographic techniques. Extensibility ensures that future attributes can be 
included into the ASProf and includes also changeability as a requirement for 
replacing attributes of a given ASProf. Relations between different attributes 
may exist. 

30 Figure 1 a shows an example of an ASProf A01 with different attributes like PIN 
B01, Smart Card B02, Biometrics B03, Transport Security B04, and Policy B05. 
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The ASProf can be extended by further attributes, e.g. for covering Future 
Technologies B06 for authentication. 



Attribute values can be assigned to the attributes of an ASProf, e.g. the set of 
5 attributes may be numeric, i.e. "key length" = "128", "minimum password length" 
= "10", or descriptive, e.g. "Transport Security" = "TLS Tunnelling" or "Transport 
Security" = "WTLS" with TLS referring to Transport Layer Security and WTLS 
referring to Wireless TLS. Referring to Fig. 1a, attribute values may be assigned 
as follows: 

10 

Attribute Attribute Value 



PIN 

Smart Card 

Biometrics (e.g. Fingerprint) 
Transport Security 
Policy 



1 0 characters 
none 

high resolution (200 kByte) 

WTLS 

none 



A further example of an ASProf with attributes coded in XML is shown below in 
20 Table A with annotations given in the following text. Relations between some of 
the attributes exist in the example below. 

<?xml version="l . 0"?> 
<ASProf> 

<user_credentials> 

<password> AA1 
<min_length>5</min_length> 
<max_length>10</raax_length> 
<max_session_duration> 
<unit>hours</unit> 
<value>8</value> 
</max_session_duration> 
<case_sensitive>yes</case_sensitive> 
<special_chars_required> 
none 

</ special_chars_required> 
<digits_required>K/digits_required> 
</password> 
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</user_credentials> 

<transport_layer_security> AA2 
<protocol> 

<type>TLS</type> 

<MAC>MD5</MAC> 

<MAC>SHA</MAC> 

<cipher>DES</cipher> 

<cipher>3DES</cipher> 
</protocol> 
<protocol> 

<type>SSL>/type> 
</protocol> 
</transport_layer_security> 

<security_policies> 
<password> 

<max_validity> 

<unit>months</unit> 
<value>6</value> 
</max_validity> 
<f irst_reuse>10</f irst_reuse> 
<privacy_policy> 

http : //www . idprovider . com/w3c/p3p . xml 
<privacy_policy> 
</password> 
<PKI> 

<trusted_CA>Verisign</trusted_CA> 
<trusted_CA>RSA</trusted_CA> 
<trusted__CA>Thawte</trusted_CA> 
</PKI> 
<liability> 

<max_liability> 
<unit>USD</unit> 
<value>0 . 00</value> 
</max_liability> 
</security_policies> 

<user_registration> 
<ID_verif ication> 

<type>email_conf irmation</type> 
</ID_verif ication> 
<expiration> 
<time> 

<unit>months</unit> 
<value>6</value> 
</time> 
</expriation> 
<renewal> 



AA4 
AA5 
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<time>never</time> 
</ renewal> 

<revocation> AA7 
<guaranteed_revocation_time> 
<unit>minutes</unit> 
<value>30</value> 
</guaranteed_revocation_time> 
</ revocation> 
</user_registration> 
</ASProf> 

Table A: Example for an ASProf coded in XML. 

Annotations to Table A: 
5 AA1 : A password is used for user authentication with minimum 5 and maximum 
10 characters. Maximum session duration until reauthentication is required is 8 
hours. Password is case sensitive, does not need to contain special characters, 
but must contain at least one numeric character. 
AA2: TLS is used to secure the transport layer, allowable message. 
10 authentication algorithms are Message Digest Algorithm No. 5 (MD5) and 
Security Hash Algorithm (SHA), allowable encryption algorithms are Data 
Encryption Standard (DES) and triple-DES. SSL is also allowed as transport 
layer security protocol, instead of TLS. 

AA3: The password must be changed at least very 6 months, an old password 
15 may not be reused until at least 10 other passwords have been used. The 
detailed privacy policy for handling user data can be found at the given URL. 
AA4: Verisign, RSA and Thawte are trusted as root certification authoritites. 
AA5: The identity provider does not assume liability ($0.00) for fraud or identity 
theft. 

20 AA6 Upon registration, the user identity is confirmed using a confirmation email 
sent to her email address. Registration expires when the account is not used for 
6 months. Regular renewal of the registration is not required. 
AA7: An account is guaranteed to be blocked (revoked) within 30 minutes in the 
case of detected fraud or leakage of credentials. 
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Multiple ASProfs are preferably related with respect to authentication security 
strength. The relations expressing the ranking or ordering of ASProfs can be 
described by means of a directed graph. In this graph, each node is an ASProf. 
The graph can have a "root node" which can be an empty ASProf, i.e. no 
5 security whatsoever. Each directed edge specifies a relation between two 
ASProfs, e.g. a ">" relation. The description of the set of ASProfs and the 
relation between ASProfs is preferably changeable, extensible, and machine 
readable. Preferably XML is used as an underlying meta-language. 

10 Special cases are conceivable, e.g. the case that the graph becomes an n- 

dimensional grid (in the case of n attributes). In this case, there are independent 
relations for each of the attributes, and the comparison of two ASProfs 
corresponds to the separate comparison of each of the attributes. As an 
example for a comparison between two ASProfs having a > relation: 

15 

IF 

key length 1 > key length 2 AND password length 1 > password length 2 
THEN 

ASProfl > ASProf2. 

20 

However, the more general graph notation allows for much more complex 
specifications, e.g. a fingerprint recognition with key length 64 is more secure 
than a password with key length 256. This case of "comparing apples with 
oranges" becomes important when completely different authentication 
25 mechanisms are used in a single system. The graph notion is more general 
than other concepts where the individual attributes are treated independently 
and allows for the expression of priorities between disparate authentication 
methods and technologies. 

30 This graph can be created in principle by each service provider, and different 
service providers may use different graphs. A service provider may have 
multiple graphs, e.g. for different users or identity providers or services. This 
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reflects the requirement that each service provider is preferably able to define 
its own preferences and priorities regarding authentication security features. A 
first service provider may consider an iris scan more secure than a keyword. A 
second service provider may consider the keyword more secure. This, of 
5 course, does not preclude the re-use of "default" graphs, if the service provider 
wishes to do so. 

In Fig. 1b, an example for an ASProf graph is depicted. The graph comprises 
ASProfs A1 , A2, A3, A4, A5, A6, A7, A8, A9 represented by points and 

10 connected by arrows for expressing a > relation between two ASProfs. The 
arrow notation used in the graphical representation of Fig. 1b means that an 
arrow connecting two ASProfs indicates with its arrowhead the one of the two 
ASProfs being > compared to the further ASProf of the two ASProfs, i.e. 
ASProfl ^ ASProf2 means ASProf2 > ASProf! Arrows 12, 13, 16, 24, 35, 47, 

1 5 58, 68, 79, 89 for expressing the > relations between the ASProfs can be found 
in the graph. 

Attributes and attribute values for smart cards, PINs, and biometrics are 
depicted that are related to ASProfs. In particular, ASProf A4 comprises a 56-bit 

20 smart card attribute B4, ASProf A7 comprises a 128-bit smart card attribute B7, 
ASProf A6 comprises a 4-digit PIN attribute B6, ASProf A8 comprises a 10-digit 
PIN attribute B8, and ASProf A9 comprises an iris recognition attribute B9. 
Further attributes or combinations of attributes can be related to the ASProfs in 
Figure 1. In addition, a root node ASProf A1 indicating "no security whatsoever" 

25 may be defined and related to ASProfs, e.g. to ASProfs A2,A3,A6 via relations 
12, 13, and 16 in Fig. 1b. Further ASProfs or relations can be included into the 
graph, existing ASProfs or relations can be altered or deleted. 

The knowledge of a PIN with 10 digits is defined to be > the knowledge of a PIN 
30 with 4 digits. This > relation is depicted by an arrow 68 starting at the ASProf A6 
comprising 4-digit PIN attribute B6 and pointing to the ASProf A8 comprising 
10-digit PIN attribute B8. The possession of a smart card with a 128-bit secret 
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key is defined to be > the possession of a smart card with a 56-bit secret key, 
Correspondingly, the > relation between the ASProf B7 and the ASProf B4 is 
expressed by an arrow 47 pointing from the 56-bit smart card to the 128-bit 
smart card. Still further, an iris recognition method may be defined > a 10 digit 
5 password as well as > a 1 28-bit secret key on a smart card with arrows 89 and 
79, respectively, expressing the respective > relation. However, it may not 
make a lot of sense to try to decide whether or not a 10 digit password is > a 
128-bit secret key on a smart card. In case that a > relation between two 
ASProfs is not feasible or not wanted, a corresponding arrow is missing in the 
10 graph. 

An example of an XML representation of the graph depicted in Figure 1b is 
given below. There are two data structures that are commonly used to represent 
a directed graph: (a) Using an adjacency list, which is a list of pairs with each 

15 pair representing a directed edge (sometimes also referred to as arrow or 

relation) with the first element of the pair specifying the originating ASProf and 
the second element specifying the terminating ASProf of the respective directed 
edge, (b) Using an incidence matrix that, for each originating node contains a 
list of terminating nodes to which edges exist in the graph. In the example given 

20 in Table B below, an incidence matrix representation is used. Other 
representations are possible. 

<?xml version="l . 0"?> 
<ASProf_graph> 



<ASProf> 



<name>AK/name> 



BB1 



<successor>A2<successor> 
<successor>A3<successor> 
<successor>A6<successor> 



</ASProf> 



<ASProf> 

<name>A2</name> 



BB2 



<successor>A4<successor> 
</ASProf> 
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<ASProf> 

<name>A3</name> 

<successor>A4<successor> 
</ASProf> 

<ASProf> 

<name>A4 < / name> 

<user_credentials> BB3 
<smart_card> 

<key_length>56</key_length> 
</smart_card> 
</user_credentials> 
<successor>A7<successor> 
</ASProf> 

<ASProf> 

<name>A5</name> 

<successor>A8<successor> 
</ASProf> 

<ASProf> 

<name>A6</name> 

<user_credentials> gg4 
<PIN> 

<digits>4</digits> 
</PIN> 
</user_credentials> 
<successor>A8<successor> 
</ASProf> 

<ASProf > 

<name>A7</name> 
<user_credentials> 
<smart_card> 

<key_length>12 8</key_length> 
</smart_card> 
</user_credentials> 
<successor>A9<successor> 
</ASProf> 

<ASProf> 

<name>A8</name> 
<user_credentials> 

<PIN> BB6 

<digits>10</digits> 
</PIN> 
</user_credentials> 
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<successor>A9<successor> 
</ASProf> 

<ASProf> 

<name>A9</ name> 
<user__credentials> 

<biometrics> BB7 

<type>iris_scan</ type> 
</biometrics> 
</user_credentials> 
</ASProf> 
</ASProf_graph> 

Table B: Example for ASProfs with relations according to Fig. 1b encoded in 
XML. 



Annotations to Table B: 
5 BB1 : A1 is the root node of the graph and stands for an empty ASProf, i.e. no 
security features at all. 

BB2: There are directed eges in the graph from the root node A1 to nodes A2, 
A3 and A6. A "successor" of a node is defined as being "stronger than or 
equally strong as" the originating node. 
10 BB3: According to Fig. 1b, attribute B4 "smart card" with attribute value "56-bit" 
is associated to ASProf A4. 

BB4:According to Fig. 1b, attribute B6 "PIN" with attribute value "4-digit" is 
associated to ASProf A6. 

BB5: According to Fig. 1b, attribute B7 "Smart Card" with attribute value "128 
1 5 bit" is associated to ASProf A7. 

BB6: According to Fig. 1b, attribute B8 "PIN" with attribute value "10-digit" is 
associated to ASProf A8. 

BB7: According to Fig. 1b, attribute B9 "Biometrics" with attribute value "iris 
recognition" is associated to ASProf A9. 

20 

Also the attributes of an ASProf may have a hierarchical structure. For example, 
a "Key Length" attribute might have different interpretations, depending on 
whether the next higher level attribute specifies "TLS Tunnelling" or "WTLS". 
Therefore, the numeric values of the "Key Length" attribute cannot always be 
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directly compared with each other without first having compared the next higher 
level attribute. 

In the case of numeric attribute values, there does not need to be a 
5 monotonous relation between the attribute value and the authentication security 
strength in the sense that e.g. a larger key length always implies higher 
authentication security strength. Figure 2 shows an example for a non- 
monotonous relation: In the example, a password length of around 9 is 
perceived as optimal in terms of authentication security strength. Shorter 

10 passwords are considered less secure because they are easier to break, e.g. by 
means of a brute-force attack in the case of very short lengths and by means of 
a vocabulary attack for longer passwords. However, passwords much longer 
than 9 are also considered less secure because they are likely to be written 
down by the user since they are too hard to remember. The relation between 

15 the attribute value "password length" and the corresponding authentication 
security strength is shown in the upper part of Figure 2. The lower part shows 
how this mapping can be represented by means of a directed graph although 
other representations are conceivable. The relation between a first ASProf with 
attribute password length and a second ASProf with attribute password length is 

20 correspondingly expressed by arrows with an arrow now expressing a stronger 
(">") relation, i.e. a first ASProf is indicated to be stronger (">") than a second 
ASProf by an arrow starting at a second ASProf and ending with its arrowhead 
at the first ASProf. The first ASProf and the second ASProf are indicated to be 
of equal strength ("=") if an additional arrow starting at the first ASProf ends with 

25 its arrowhead at the second ASProf. For example, a "=" relation stating that the 
strength of two password lengths are equal is expressed by two arrows with one 
arrow pointing from the first password length to the second password length 
and a second arrow pointing from the second password length to the first 
password length. In this example, passwords having 11-20 characters are 

30 defined to be of equal authentication security strength as passwords with 3-6 
characters. 
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In fact, it can be left completely to the service provider to decide about its own 
preferences and priorities, e.g. a first service provider may decide for a 
monotonous mapping and a further service provider may decide on a mapping 
according to Fig. 2, and a third service provider may accept a default graph by 
5 an identity provider without caring about the details of the mapping. 

The example of Figure 2 illustrates how a non-monotonous relation can be rep- 
resented in a directed graph. It further illustrates how ranges of attribute values, 
e.g. "7-10 characters", in the graph representation can be collapsed into a 
10 single node, i.e. there is no requirement that each allowed numeric value forms 
a separate node in the graph. 

In the following, the authentication of a user to a service of a service provider 
SP by one or more identity providers is described: 

15 

According to Fig. 3, a client contacts a service, provided by a service provider 
SP, that the user wants to invoke by sending via message 1a a service request. 
The service requires a user authentication and the service provider SP sends 
via message 1b a request for user authentication to the client. The client 

20 provides via message 1c a user identity to the service provider SP that can 
verify the user identity. If the identity provider ldP1 for authentication of the 
client is unknown to the service provider SP, the client sends via message 1c a 
reference to an identity provider ldP1, e.g. a Uniform Resource Identifier (URI), 
to the SP. Optionally, the reference to the identity provider ldP1 is send from the 

25 client to the service provider SP by default. 

The service provider SP requests authentication of the user by sending via 
message 2 a desired ASProf specifying the authentication security 
requirements of the service and the user identity to the identity provider ldP1 . 
30 Typically, the service provider SP and the identity provider ldP1 are setting up a 
secure session (e.g. using TLS) that provides confidentiality, integrity and 
authenticity of the information they exchange, as well as unilateral or mutual 
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authentication between the service provider SP and the identity provider ldP1. 
Processes and messages that are necessary for any kind of encryption 
between any kind of entites involved in the proposed authentication method are 
not depicted in Fig. 3 nor in the following figures. 

5 

The identity provider ldP1 checks in process 3a whether or not it can meet the 
requirements set forth in the ASProf received from the SP. If the requirements 
can be met, the identity provider ldP1 can further check in process 3a whether a 
verification of user credentials is required or not. If credential verification is 

10 necessary, a request 3b for user credentials can be sent to the client, and the 
client can respond via message 3c to that request 3b by providing the 
requested user credentials. Both, in- and out-of-band communication is possible 
for the request 3b and the corresponding response 3c. Based on a positive 
result for the check of the requirements of the ASProf and of the optional 

15 credential verification, the identity provider ldP1 sends via message 3d an 
assertion of the user authentication to the SP. Based on the assertion, the 
service provider SP can grant access to the client to access the requested 
service session. 

20 As an example for verification of user credentials: A user has authenticated 
using a username/password mechanism to its favorite web portal at 9 am, via 
an IdP. At 1 1 am the user wants to access his profile at a service provider 
providing a service for Internet book sales with said service provider also 
accepting authentication assertions from the same IdP. If said service provider 

25 requires, in its ASProf, that the password entry may not be more than one hour 
old, the IdP needs to ask the user to re-enter a password before the user can 
be authenticated to said service provider. If, on the other hand, said service 
provider accepts password entries that are up to 24 hours old, there is no need 
for re-entering the password. 

30 

According to Fig. 3 and the description of Fig. 3, only one ASProf is sent from 
the service provider SP to the identity provider ldP1 . However, the proposed 
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method can be easily adapted to the case that multiple desired ASProfs are 
sent from the service provider SP to the identity provider ldP1 . In this case, the 
service provider SP sends a "wish list" of ASProfs the service provider SP 
considers as sufficient for authentication of the client. The identity provider ldP1 
5 checks the wish list. If one or more of the ASProfs of the wish list are supported 
by the identity provider ldP1 , the identity provider ldP1 may select the one of 
the ASProfs that is supported best by the identity provider ldP1 , e.g. where no 
credential verification is necessary or credential verification is less difficult 
compared to further supported ASProfs of the wish list. 

10 

The method described in conjunction with Fig. 3 uses a "back channel" 
message flow, involving a direct message exchange between the identity 
provider ldP1 and the SP. Alternatively, the method can be implemented using 
a "front channel" communication, i.e. any communication between the identity 
15 provider ldP1 and the service provider SP is relayed by the client preferably 
using appropriate security precautions so the client cannot tamper with the 
information passed back and forth. A combination of back channel and front 
channel for different messages is possible as well. 

20 An example for a front channel communication is depicted in Fig. 4 for an 
authentication corresponding to Fig. 3. In front-channel communication, the 
desired ASProf and optionally the user identity are sent via message 42a from 
the service provider SP to the client. The client sends via message 42b the 
desired ASProf and the user identity to the identity provider ldP1 . If the user 

25 identity is not provided by the service provider SP, the client obtains the user 
identity and sends it via message 42b to the identity provider ldP1 . As in Fig. 3, 
the identity provider ldP1 can check in process 3a the received ASProf and if a 
credential verification is necessary. If so, the identity provider ldP1 can verify 
the user credentials using messages 3b,3c. As in Fig. 3, messages 3b,3c are 

30 optional and in- or out-band communication may be utilized. The security 

assertion as given by the identity provider ldP1 is sent via messages 43d, 43e 
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via the client to the service provider SP. In this case, the security assertion can 
be considered as an authentication token or ticket. 

In the case of a mobile client, a back-channel implementation has the 
5 advantage of avoiding communication between the service provider SP and the 
identity provider ldP1 over the air interface of the client. For front-channel 
communication, extra bandwidth is used and extra latency is caused on the air 
interface for the sole purpose of passing information back and forth between the 
service provider SP and the identity provider ldP1. 

10 

A front channel approach is common for fixed networks like the Internet and 
may be preferred compared to a back channel approach in order to reduce 
implementation effort. It has also the advantage that a session redirection takes 
place, i.e. the request to the service provider SP in 1c of Fig. 4 is answered by a 
15 reply from the service provider SP in message 42a and not as in the back 
channel case by a reply from an identity provider ldP1 . This may cause the 
overall time needed for the authentication to be shorter than for back channel 
communication. 

20 A hybrid implementation, e.g. using a proxy server, may also be possible in 
order to emulate a front channel for the communication between the service 
provider SP and the identity provider ldP1 while avoiding traffic via the client. A 
hybrid implementation may be therefore very useful for a mobile client. 

25 For the case, the identity provider ldP1 as described in conjunction with Fig. 3 
does not support the desired one or more ASProfs sent from the service 
provider SP to identity provider ldP1, the identity provider ldP1 can provide the 
service provider SP with a counterproposal for the one or more desired 
ASProfs. According to Fig. 5, the service provider SP sends via message 2 a 

30 request for authentication comprising the desired ASProf and the user identity 
to the identity provider ldP1 . The identity provider ldP1 checks the received 
desired ASProf and realizes that the desired ASProf is not supported. One or 
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more alternative ASProfs are determined and sent via message 4 as proposed 
alternative ASProfs from the identity provider ldP1 to the SP. The service 
provider SP checks in process 5a if at least one of the one or more proposed 
alternative ASProfs is acceptable. If none of the received proposed alternative 
5 ASProfs are acceptable, the service provider SP may send one or more further 
desired ASProfs to the identity provider ldP1 or may contact a further identity 
provider ldP1 for authentication or may terminate the authentication. If at least 
one of the one or more proposed alternative ASProfs is acceptable, the service 
provider SP sends via message 5b an approval of the at least one proposed 

10 alternative ASProf to the identity provider ldP1 . If multiple proposed alternative 
ASProfs are acceptable, the service provider SP may select one of the multiple 
ASProfs before sending the approval on the selected ASProf, e.g. the service 
provider SP may check the received one or more proposed alternative ASProfs 
and stops the checking after a first ASProf is found to be acceptable. This 

1 5 ASProf is approved by the service provider SP and an indication of the approval 
of this ASProf is sent to the identity provider ldP1 . For the approved ASProf, the 
identity provider ldP1 proceeds with processes and messages 3a-3d as 
described in conjunction with Fig. 3. 

20 As described above in conjunction with Fig. 3-5, the service provider SP desires 
one or more ASProfs to be used by the identity provider ldP1 in the sense that 
the desired one or more ASProfs are sent to the identity provider ldP1 . 
However, the service provider SP does not necessarily have to send the one or 
more desired ASProfs to the identity provider ldP1 in the request for 

25 authentication. Instead, the service provider SP can request a list of supported 
ASProfs from the identity provider ldP1. This is shown in Fig. 6. The service 
provider SP sends via message 62a the user identity to the identity provider 
ldP1 and requests authentication. The identity provider ldP1 responds via 
message 62b with a list of ASProfs supported by the identity provider ldP1 . The 

30 list is checked in process 62c by the service provider SP and an acceptable 
ASProf of the list is selected. The selected ASProf (as one example for an 
indication) or an indication of the selected ASProf is sent via message 62d to 
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the identity provider ldP1 . The sending of the selected ASProf (as one example 
for an indication) or of the indication may be supplemented by the user identity 
for correlating the selected ASProf with the request for authentication sent via 
message 62a. The identity provider ldP1 can check in process 63a if a 
5 credential verification is necessary for the selected ASProf and proceeds with 
processes and messages according to 3b-3d as described in conjunction with 
Fig. 3. 

Sending of ASProfs can be achieved by sending individual ASProfs with or 
10 without relation revealing the level of security strength. Individual ASProfs or 
ASProfs and information on the relation between the ASProfs can be sent. For 
example, with respect to the graph notation as described in conjunction with 
Fig. 1 and 2, the full graph or parts of the graph like ASProfs and arrows can be 
sent. The sender, e.g. the service provider SP, of the ASProfs can specify 
15 which ASProfs are desired to be used by the receiver, e.g. the identity provider 
ldP1 . Especially in the case that the receiver does not support any of the 
desired ASProfs, the receiver can navigate through the graph starting at the 
desired ASProfs to see whether it can support an ASProf that is recognized as 
equal or stronger than a desired ASProf if information on the relation between 
20 ASProfs is available at the receiver. When navigating through the graph or parts 
of the graph known to the receiver, the receiver can select at least one ASProf 
that is equal or stronger for meeting the requirements with respect to the 
strength of the ASProf as desired by the sender. 

25 A corresponding example for a navigation is depicted in Fig. 7, wherein the 

service provider SP sends via message 72 a part of or the full ASProf graph, an 
indication for the desired ASProf, and the user identity to the identity provider 
ldP1 for authentication. Instead of sending the full graph, the service provider 
SP can send only that part of the graph comprising ASProfs being equal or 

30 stronger than the desired ASProf, e.g. in order to lower transmission effort or 
not to provide the identity provider ldP1 with information not usuable for this 
authentication. The identity provider ldP1 checks in process 73a if the desired 
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ASProf is supported. If it is not supported, the identity provider ldP1 checks in 
process 73a if a stronger ASProf (as depicted in Fig. 7) or an ASProf of equal 
strength is supported by navigating the graph as received from the SP. If at 
least one ASProf being stronger or of equal strength different from the not 
5 supported desired ASProf is supported by the identity provider ldP1 , the identity 
provider ldP1 may check in process 73a for verification of user-credentials and 
request them from the user if necessary as described in conjunction with Fig. 3 
(process and messages 3a-3c). If an equal or stronger ASProf is used and 
optionally the user credentials are verified, the identity provider ldP1 sends via 

10 message 73d an assertion of the user authentication preferably supplemented 
by an indication of the used equal or stronger ASProf to the identity provider 
ldP1 . Before granting service access for the client, the service provider SP can 
check in process 73e if the used ASProf is acceptable for the service provider 
SP, e.g. complies with the authentication security requirements of the service 

15 provider SP. 

The transmission of the graph or parts of the graph as explained above makes 
the proposed method much more efficient in terms of the number of message 
roundtrips if the service provider SP and identity provider share - at least to a 

20 certain extent - similar ideas of what makes an ASProf stronger or equally 

strong compared to another ASProf, i.e. they share information on ASProfs and 
the relations between ASProfs with respect to authentication security strength. 
In addition, transmitting the graph has the advantage of minimizing the number 
of message round-trips between service provider SP and identity provider, thus 

25 making the authentication service much faster while still guaranteeing that the 
SPs security preferences and priorities are observed. 

For example, if a service provider SP requests a key length of 128 bit, and the 
identity provider can only provide either 64 bit or 256 bit, then it is beneficial that 
30 the service provider SP and identity provider share the notion that a 256 bit key 
is accepted to be stronger by the service provider SP than a 128 bit key. If this 
notion is not shared, then additional messages need to be exchanged until the 
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service provider SP and the identity provider can agree on an ASProf to be 
applied. Without the knowledge of the relation that a 256 bit key is stronger than 
128 bit key, the identity provider sends for example an indication to the service 
provider SP that 128 bit keys are not supported. For this case, the service 
5 provider SP can respond with an alternative ASProf of 256 bit which is 
supported. 

The shared notion of whether or not an ASProf is equal or stronger than another 
can be implicit or explicit. An example for an implicit agreement is the 128 bit vs. 

10 256 bit case above meaning that 256 bit is generally understood to be stronger 
than 128 bit. The identity provider who cannot provide 128 bit uses 256 bit 
instead and communicates this fact to the service provider SP in the ASProf, 
assuming that the service provider SP will find 256 bit acceptable when the 
service provider SP has requested 128 bit. However, if the service provider SP 

1 5 has used a different definition of the strength of an ASProf than the identity 
provider, the wrong assumption of the identity provider leads to additional 
renegotiation and additional messages or termination of the authentication. An 
example where an explicit shared notation between the service provider SP and 
the identity provider is preferable compared to an implicit shared notation is 

20 given in Fig. 2 where the service provider SP defines a non-monotonous and 
not generally agreed upon relation between a numeric attribute and the 
perceived authentication security strength. 

Fig. 8 shows an authentication where the service provider SP sends via 
25 message 2 a request for authentication comprising the desired ASProf and the 
user identity but without sending further information on a graph of the SP. The 
identity provider ldP1 does not support the desired ASProf and the identity 
provider ldP1 chooses an alternative ASProf as shown in process 83a. The 
identity provider checks if a credential verification is necessary in process 83a. 
30 After an optional verification of user credentials using message 3b and 3c 
according to the explanations given in conjunction with Fig. 3, the assertion of 
user authentication and an indication of the used alternative ASProf is sent via 
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message 83d to the SP. The service provider SP checks in process 83e 
whether the alternative ASProf is acceptable or not. If the ASProf is acceptable, 
the service session may start. For choosing the alternative ASProf, the ASProf 
may use its own notation, e.g. by using an own graph or assuming an explicit 
5 notation. However, in order to avoid that the service provider SP finds the 
alternative ASProf unacceptable, the identity provider ldP1 uses preferably a 
notation shared between the service provider SP and the identity provider ldP1 . 
A graph reflecting the ordering according to the service provider SP may be 
provided when registering the service provider SP to the authentication service 
10 provided by the identity provider ldP1. However, for ad-hoc scenarios where no 
further information than the desired ASProf and the user identity is available at 
the identity provider ldP1, the identity provider ldP1 may preferably uses its own 
notation, e.g. its own graph, or may request one or more supported ASProfs, 
e.g. in form of a graph, from the identity provider. 

15 

By associating ASProfs with relations, groups of ASProfs of can be created. For 
example, a number of ASProfs may be related by relating each pair of said 
number of ASProfs by = relations thus forming a group of ASProfs of equal 
authentication security strength, e.g. as indicated in Fig. 2 by the ASProfs with 

20 3-6 and 1 1-20 characters forming a group of equal authentication security 

strength. The service provider can indicate to the identity provider to use any of 
the ASProfs belonging to a certain group for the authentication of the user by 
selecting one of the ASProfs belonging to that group and to send an indication 
of the selected ASProf to the identity provider for authentication of the user. If 

25 the identity provider is aware of the indicated group, e.g. due to the fact that 
information about the characteristics of the group, i.e. the ASProfs and their 
relations, is provided by the service provider SP to the IdP or vice versa, the 
identity provider can select one ASProf for authentication from the group based 
on the indication. A group identifier may be used for indication of the group to 

30 the identity provider if the service provider and the identity provovider share the 
same notation of the group. Individual groups may be ordered hierarchically, 
e.g. a first group comprising of a first number of ASProfs may be related to a 
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second group of ASProfs and the identity provider may navigate from one 
group to another group for authentication. For checking if the ASProf based on 
which the authentication is executed matches to the authentication security 
requirements of the service provider, an indication of the group said 
5 authentication security profile is related to may be sufficient. Forming groups 
may have the advantage of a better scalability and manageability of 
authentication security profiles with comparable characteristics like comparable 
credential types or a comparable creation or validity periods. 

10 As an alternative authentication method, the service provider SP can ask for an 
authentication without specifying any ASProf. A corresponding scenario is 
depicted in Fig. 9. The service provider SP sends via message 62a a request 
for authentication comprising a user identity to the identity provider ldP1 . The 
identity provider ldP1 uses an ASProf of its own choice as indicated in process 

15 93a and optionally executes a credential verification according to the chosen 
ASProf by e.g. utilizing messages 3b,3c as explained in conjunction with Fig. 3. 
Then, the identity provider ldP1 sends via message 93d an indication of the 
used ASProf or, as an alternative form of an indication, the used ASProf itself 
to the service provider SP together with the assertion of authentication. The 

20 service provider SP then decides whether or not to accept the authentication, 
i.e. it is checked in process 93e if the used ASProf is acceptable or not. 

The method for upgrading a user authentication to a service provider SP by an 
identity provider during a service session is described in the following two 

25 figures 10 and 1 1 . According to Fig. 10, a client participates in a service 

session. Establishment of the service session with a first authentication of the 
user to the service of the service provider may be achieved according to the 
description of Fig. 3 to 9. During the service session, the client accesses a 
service that requires a higher security level than the established session. An 

30 example for a higher security level is that a user can access his online bank 
account by means of a 5-digit PIN code. However, if the user in addition wants 
to authorize a monetary transaction from his bank account, an additional one- 
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time password, or TAN, is required. Another example, a user can access his 
personalized web portal by means of a password. Some services on the portal 
may be subject to a fee. When the user clicks on such a service, an 
authentication using a smart-card reader attached to the user's PC may be 
5 required. 

The service provider SP detects the service request sent via message 102a 
from the client to the service provider SP and selects an ASProf, called in the 
following modified ASProf, meeting the tighter requirements, i.e. the modified 

10 ASProf is stronger as the ASProf used for first authentication. The service 
provider SP sends via message 102b a request for authentication comprising 
the modified ASProf and the user identity to an identity provider not necessarily 
identical with an identity provider used for the first authentication. The identity 
provider ldP1 checks in process 103a whether it is capable of meeting the 

15 stronger ASProf requirements. If it is, the identity provider ldP1 checks in 

process 103a whether this stronger ASProf requires a new verification of user 
credentials and performs via messages 103b,103c this verification if necessary. 
As in Fig. 3, the optional messages 103b,103c may be exchanged via in- or 
out-band communication. It is then proceeded as described as in conjunction 

20 with Figure 3 with respect to the assertion of the user authentication sent from 
the identity provider ldP1 to the service provider SP via message 103d. Based 
on the assertion, the service provider SP can grant access to the service 
requiring the upgraded ASProf and the service session can be continued. 
Instead of sending the selected ASProf (as one form of an indication), an 

25 indication like a URI for the selected ASProf can be send, e.g. when the 
selected ASProf is known or accessible to the identity provider ldP1 . If the 
ASProf used in the first authentication is known to the identity provider ldP1 , the 
service provider SP may instead send an indication to use an ASProf stronger 
than the ASProf used in the first authentication. In this case, the identity 

30 provider ldP1 can execute the selection of the modified ASProf, e.g. by 
navigating a graph. Preferably, this modified ASProf used for the upgrade 
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authentication is indicated to and approved by the service provider SP for 
upgrade authentication. 

Fig. 11 shows the case where an authentication and a service session have 
5 been established by a first identity provider ldP1 and the client requests service 
access to a service requiring a higher security level than the established 
session. The service provider SP accordingly detects the service request sent 
via message 102a requiring the higher security level and sends via message 
102b a request for authentication comprising the modified ASProf and the user 

10 identity to the first IdP. The first identity provider ldP1 checks in process 113a1 
the received modified ASProf and detects that the modified ASProf is not 
supported. Accordingly, the first identity provider ldP1 sends a refusal via 
message 1 13b of the modified ASProf and optionally alternative ASProfs that 
are supported by the first identity provider ldP1 . The service provider SP can 

1 5 check in process 1 1 3c the alternative ASProfs and may find them 

unacceptable. A response to the refusal may be sent to the first identity provider 
ldP1 for indicating that the authentication is terminated with respect to the first 
identity provider ldP1 . At this point the service provider SP can terminate the 
authentication upgrade or can choose a second identity provider ldP2 for 

20 authentication upgrade. If a second identity provider ldP2 is available, a further 
request for authentication is sent via message 112b to the second identity 
provider ldP2. The further request comprises the modified ASProf and a user 
identity being identical or not identical to the user identity used for the first 
authentication at the first identity provider ldP1 . The second identity provider 

25 ldP2 checks in process 1 13a2 if the modified ASProf is supported. If the 

modified ASProf is supported, a verification of user credentials can be executed 
if necessary, e.g. by utilizing messages 113b, 113c via in- or -out-band 
communication. An assertion of the user authentication is sent via message 
113d to the SP. Based on that assertion, the service provider SP can grant 

30 access to the service having tighter security requires and the service session 
can be continued. 
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Further exemplary upgrade scenarios are: A user is authenticated via a 
password by his Internet Service Provider (ISP) sometimes also named Internet 
Access Provider. At some point in time, the user wants to access a video 
streaming service which is subject to a fee and which requires stronger 
5 authentication, e.g. via a mobile phone (Subscriber Identity Module / Wireless 
Identification Module, SIM/WIM) as an authentication token. The service 
provider, i.e. the provider for the video service streaming service, first contacts 
the ISP for an authentication upgrade. The ISP since it typically does not 
manage SIM's and mobile phones, but probably only simple password lists 

1 0 cannot meet the tighter ASProf. It may propose a weaker ASProf to the service 
provider, but the service provider refuses. The service provider then contacts 
the user's mobile operator which can have been specified by the client in the 
initial service request as a potential identity provider. The mobile operator as an 
identity provider is capable of meeting the specified ASProf, i.e. requiring 

1 5 possession of a specific SIM/WIM as well as knowledge of a PIN-code. It sends 
the assertion of the stronger authentication to the service provider, so that the 
user may proceed using the streaming service. 

It is not necessary to explicitly spell out the complete set of attributes of the 
20 ASProf every time whenever an ASProf is sent from an identity provider to a 
service provider or vice versa. Correspondingly, relations between ASProfs or 
even the full graph do not have to be sent in total. Instead, references (URI's) 
as well as updates can be used in order to reduce the amount of data being 
exchanged, as explained in the following. 

25 

An ASProf may consist of a sequence of fragments, each specifying one or 
more attributes, e.g. compare the XML description according to Table A with 
fragments relating to <user_ credentials>, <transport_layer_security>, 
<security_policies>, and <user_registration>. Attributes from the individual 
30 fragments either complement each other, i.e. if they are only present in one 

fragment or override each other, i.e. if they are present in both fragments. In the 
case of overriding, a priority convention based on the order of the fragments 
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needs to be specified, i.e. subsequent fragments override preceding ones, or 
vice versa. 

A reference, e.g. preferably a URI, can be used to refer to an ASProf or to a 
5 fragment preferably representing a semantic subset of the full ASProf instead of 
explicitly spelling out all attributes of that ASProf or fragment. The use of 
references enables fetching and caching and can substantially reduce the 
amount of data being sent back and forth. For example, when a service provider 
frequently uses a certain identity provider that uses the same ASProf for a 
10 certain time period, there is no need for the ASProf to be explicitly exchanged 
between the service provider and the identity provider every time a new user is 
authenticated within said certain time period. 

The use of updates of ASProfs in the sense of a delta updating relating to 
1 5 differences between existing ASProfs and newer ASProfs can further reduce 
the amount of data being exchanged. An update ASProf is a newer ASProf that 
either complements an existing ASProf or overrides some of its attributes. Also 
update fragments or update attributes are possible. For example, a user has 
been authenticated to a service provider by an identity provider using a 
20 password verification. For a certain user interaction, an authentication upgrade 
is required where the only difference to the previously used ASProf is that a 
shorter time-to-live for the password verification is specified. In this case, it is 
clearly more efficient to send a reference to the previously used ASProf, plus a 
single attribute specifying the deviating time-to-live attribute, as opposed to 
25 sending a reference to a new ASProf which the receiving party would have to 
fetch and cache completely. 

The proposed method is embodied also in devices like servers associated with 
a service provider, an identity provider, or proxy, or a client device. Such 
30 devices comprise at least a receiving unit R for receiving messages M2, a 
transmitting unit T for sending messages M1 , and a processing unit P for 
processing of messages and information, and preferably a database D for 
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storing information. An example for such a device is depicted in Fig. 12 showing 
the units R,T,P,D and messages M1.M2 and interconnections PR,PT,PD for 
exchanging information and messages between the individual units R,T,P,D. 
The device DEV is an example for a device that can be employed by the service 
5 provider, the identity provider, or the user as client device for implementing the 
method. 

Examples for devices and links for exchanging messages and information 
between devices for executing the authentication method are given in Fig. 13, 
10 14 and 15 for back channel, front channel, and hybrid back/front channel 

communication, respectively. The devices can be composed as depicted and 
described in conjunction with Fig. 12. 

Fig. 13 shows a client D12, a service provider D10, and an identity provider D1 1 

15 and links CON10, CON11, CON 12 between the three parties for authentication 
of the client D12 to the service provider D10 via front channel communication. 
Communication between the client D12 and the service provider D10 is 
performed via link CON 10, communication between the service provider D10 
and the identity provider D1 1 is performed via link CON1 1 , and communication 

20 between the identity provider D1 1 and the client D12 is performed via link 

CON12. Examples for information and messages exchanged between the three 
parties via link CON10, CON11, CON12 can be found for example in Fig. 3, i.e. 
service request (message 1a), request for authentication (message 1b), user 
identity and reference to identity provider (message 1c) and service session via 

25 link CON 10, the desired ASProf and user identity (message 2) and the 

assertion of the user authentication (message 3d) via link CON1 1 , and request 
for user credentials (message 3b) and the delivery of the user credentials 
(message 3c) via linkCON12. The links CON10, CON11, CON12 can be but do 
not need to be stationary connections, e.g. link CON 12 may be achieved via 

30 Short Message Services (SMS) if the client D1 2 is a mobile phone. 
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Fig. 14 shows a client D22, a service provider D20, and an identity provider D21 
and links CON20, CON21 between the three parties for authentication of the 
client D22 to the service provider D20 via front channel communication. In 
contrast to Fig. 1 1 , no direct link exists between the service provider D20 and 
5 the identity provider D21 . Instead, communication between the service provider 
D20 and the identity provider D21 is achieved via the client D22 in the sense 
that the information to be exchanged between the service provider D20 and the 
identity provider D21 is relayed by the client D22. Examples for information and 
messages exchanged between the three parties via link CON20 and CON21 

10 can be found in Fig. 4, i.e. service request (message 1a), request for 

authentication (message 1b), user identity and reference to identity provider 
(message 1c), and service session are sent via link CON20. Correspondingly, 
the request for user credentials (3b) and the user credentials is sent via link 
CON21 . However, the desired ASProf and the user identity comprised in the 

15 request for authentication (messages 42a,42b) are sent from the service 

provider D20 via the client D22 to the identity provider D21 via links CON20 and 
CON21 . A corresponding relaying is achieved for the assertion of the user 
authentication (messages 43d,43e) sent from the identity provider D21 to the 
service provider D20 via the client D22 via links CON21 and CON20. 

20 

Fig. 15 shows a hybrid implementation using a proxy D31 for emulating front 
channel implementation. For authentication of the user of the client D33 to a 
service of the service provider D30, the client D33 sends a service request to 
the service provider D30 via link CON30. The service provider D30 responds 

25 with a request for user authentication to the client via link C30 and the client 
D33 provides the service provider D30 with the user identity and optionally a 
reference to the identity provider D32 via link CON30. For communication 
between the service provider D30 and the identity provider D32, e.g. for sending 
the user identity and the desired ASProf or for the assertion of user 

30 authentication, a proxy D31 is interposed between the service provider D30 and 
the identity provider D32. Information from the service provider D30 to the 
identity provider D32 and vice versa can be sent via the proxy D31 using the 
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connections CON31 and CON32. For the request of user credentials and the 
delivery of user credentials, link CON35 may be used. Alternatively, link CON32 
and link CON34 can be used for the request and the delivery of user 
credentials. Further information may be exchanged between the proxy D31 and 
5 the client D33 via link CON34. 

The method according to the invention is embodied also in one or more 
computer programs loadable to devices associated to a service provider, 
identity provider, proxy, or client. The one or more computer programs comprise 

10 portions of software codes in order to implement the method as described 
above. The one or more computer programs can be stored on a computer 
readable medium. The computer-readable medium can be a permanent or 
rewritable memory within a server or a server or located externally. The 
computer program can be also transferred to a server for example via a cable or 

15 a wireless link as a sequence of signals. 

The proposed method can be adapted to be used in 2G and 3G mobile 
telecommunication systems like GPRS and UMTS, respectively. It can also be 
applied for authentication to services in fixed networks like the Internet and 

20 combinations of fixed and wireless networks including Wireless Local Area 
Networks (WLAN).Mobile and stationary client terminals can be employed by 
the user. The servers associated to a service provider, identity provider, or 
proxy typically are stationary in a network. However, the proposed method can 
be applied for moving, non-stationary servers. Examples for servers are 

25 Personal Computers (PCs) or laptop computers. 

In the following, some of the advantages of the invention are summarized: 

Rather than having fixed relationships between service providers and identity 
30 providers with static authentication security policies, the invention can provide 
ad-hoc negotiation and upgrading of authentication security profiles. For ad-hoc 



WO 03/100544 



50 



PCT/EP03/05421 



negotiation, no prior agreement between a service provider and identity 
provider about ASProfs is required. 

Furthermore, different types of services and transactions can have very different 
5 requirements on the certainty of knowing that a user is who he claims to be. 
Likewise, different authentication mechanisms and security infrastructures 
provide different levels of certainty. The proposed method supports these 
different levels of certainty thus overcoming restrictions common with binary 
authentication concepts. 

10 

Another advantage is that the invention provides a flexible model that allows for 
on-the-fly changes of policies both on the service provider and on the identity 
provider side. If policies and security features change, out-of-band 
communication between service provider and the identity provider can be 
15 minimized. 

Furthermore, the authentication method allows to handle complex specifications 
of ASProfs, i.e. different types of attributes like fingerprint recognition and 
password can be compared with respect to authentication security strength. 
20 Furthermore, also combinations of different attributes can be negotiated making 
the proposed method even more versatile. 

Also, the authentication method empowers the service respectively the service 
provider to act as the policy decision and policy enforcement point taking in the 

25 end the decision on the authentication. For this service provider friendly case, 
the proposed invention can be implemented such that the identity provider 
provides the service of validating user credentials and the identity provider is 
preferably only involved in session establishment or for authentication updates. 
Not further requiring the identity provider during a session, consequently 

30 reduces the load of the identity provider and the complexity of its session 
management, and improves scalability compared to prior art authentication 
methods with an intermediate identity provider. 
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Claims 

1 . Method for an authentication of a user to a service of a service provider 
(SP), comprising the steps of 

5 - Requesting access for the user to the service of the service 

provider (SP), 

- Selecting by the service provider (SP) one or more authentication 
security profiles for specifying an authentication security 
requirement for the authentication of the user to the service, 

1 0 - Sending an indication of the one or more selected authentication 

security profiles and a user identity identifying the user to an 
identity provider (ldP1 ) for requesting the authentication of the 
user by the identity provider (ldP1), 

- Authenticating the user based on the user identity and one of the 
1 5 one or more selected authentication security profiles, and 

- Sending an assertion indicating the authentication of the user to 
the service provider (SP). 

2. The method according to claim 1 , wherein the one or more authentication 
20 security profiles comprise at least one security attribute for specifying the 

authentication security requirement. 

3. The method according to claim 1 or 2, wherein the service provider (SP) 
selects the one or more authentication security profiles from a group of 

25 one or more security profiles that are indicated to be supported by the 

identity provider (ldP1 ) for the authentication. 



4. 

30 



The method according to claim 3, wherein the service provider (SP) 
receives an indication for the group of the one or more supported 
security profiles from the identity provider (ldP1). 
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5. The method according to any of the preceding claims, wherein said one 
authentication security profile based on which the authentication is 
executed is selected by the identity provider (ldP1) from the selected 
authentication security profiles. 

5 

6. The method according to any of the preceding claims, wherein the one or 
more selected authentication security profiles are related by one or more 
relations to one or more further authentication security profiles, each 
relation expressing an ordering of the one or more selected 

10 authentication security profiles to the one or more further authentication 

security profiles regarding an authentication security strength, and the 
step of authenticating the user is executed by 

- selecting by the identity provider (ldP1 ) one of the one or more 
further authentication security profiles being related equally strong 

1 5 or stronger regarding the authentication security strength 

compared to the one or more selected authentication security 
profiles, and 

- authenticating the user based on the selected further 
authentication security profile. 

20 

7. The method according to claim 6, wherein the service provider (SP) 
specifies the one or more relations to the one or more further 
authentication security profiles and the service provider (SP) sends an 
indication of the one or more relations to the one or more further 

25 authentication security profiles to the identity provider (ldP1 ). 

8. The method according to any of the preceding claims, wherein the 
assertion is supplemented by an indication of the authentication security 
profile based on which the authentication is executed and the indicated 

30 authentication security profile is checked by the service provider (SP) for 

acceptance. 
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9. A method for an authentication of a user to a service of a service provider 
(SP), comprising the steps of 

- Requesting access for the user to the service of the service 
provider (SP), 

5 - Sending a user identity identifying the user to an identity provider 

(ldP1 ) for requesting the authentication of the user by the identity 
provider (ldP1), 

- Authenticating the user based on the user identity and an 
authentication security profile, 

10 - Sending an assertion indicating the authentication of the user to 

the service provider (SP), the assertion being supplemented by an 
indication of the authentication security profile, and 

- Checking by the service provider (SP) the indicated authentication 
security profile for acceptance. 

15 

10. The method according to any of the preceding claims, further comprising 
the step of receiving at the service provider (SP) from a user device the 
user identity and a reference to the identity provider (ldP1) in response to 
a request for authentication sent from the service provider (SP) to the 

20 user device. 



, 1 1 .The method according to any of the preceding claims, further comprising 
the step of granting access to the service based on the assertion. 

25 12. The method according to any of the claims 8 to 10, further comprising the 
step of granting access to the service based on the assertion and the 
check for acceptance. 



13. The method according to any of the preceding claims, further comprising 
30 the step of an authentication upgrade, the authentication upgrade being 

executed by performing a further authentication based on at least one 
further authentication security profile. 
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14. The method according to claim 13, wherein the authentication upgrade 
comprises a change to a further identity provider (ldP2) for executing the 
further authentication of the user based on the further authentication 
5 security profile. 



15. A device associated to a service provider (SP), the device comprising a 
receiving unit for receiving messages, a transmitting unit for sending 
messages, and a processing unit for processing messages and 
1 0 information, wherein the device is adapted to 

- receive a request for access of a user to a service of the service 
provider (SP), 

- select one or more authentication security profiles for specifying 
an authentication security requirement for an authentication of the 

15 user to the service, 

- send an indication of the one or more selected authentication 
security profiles and a user identity identifying the user to an 
identity provider (ldP1) for requesting the authentication of the 
user by the identity provider (ldP1), and 

20 - to receive an assertion indicating the authentication of the user by 

the identity provider (ldP1). 



16. The device according to claim 15, wherein the device is adapted to select 
the one or more authentication security profiles comprising at least one 
25 security attribute for specifying the authentication security requirement. 



17. The device according to claim 15 or 16, wherein the device is adapted to 
select the one or more authentication security profiles from a group of 
security profiles that are indicated to be supported by the identity 
30 provider (ldP1 ) for the authentication. 
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18. The device according to claim 17, wherein the device is adapted to 
receive an indication for the group of the one or more supported security 
profiles from the identity provider (ldP1). 

5 19. The device according to any of the claims 15 to 18, wherein the device is 
adapted to relate the one or more selected authentication security 
profiles to one or more further authentication security profiles, each 
relation expressing an ordering of the one or more selected 
authentication security profiles to the one or more further authentication 
10 security profiles regarding an authentication security strength, and the 

device is further adapted to send at least the one or more relations to the 
one or more further authentication security profiles being related equally 
strong or stronger regarding the authentication strength to the identity 
provider (ldP1 ) for the authentication. 

15 

20. The device according to any of the claims 15 to 19, wherein the device is 
adapted to receive an indication of the authentication security profile 
based on which the authentication of the user is executed by the identity 
provider (ldP1 ) and the device is further adapted to check the indicated 

20 authentication security profile for acceptance. 

21. A device associated to a service provider (SP), the device comprising a 
receiving unit for receiving messages, a transmitting unit for sending 
messages, and a processing unit for processing messages and 

25 information, wherein the device is adapted to 

- receive a request for access of a user to a service of the service 
provider (SP), 

- send a user identity identifying the user to an identity provider 
(ldP1 ) for requesting an authentication of the user by the identity 

30 provider (ldP1), 



WO 03/100544 PCT/EP03/05421 



- receive an assertion indicating the authentication of the user from 
the identity provider (ldP1), the assertion being supplemented by 
an indication of the authentication security profile, and 

- check the indicated authentication security profile for acceptance. 

5 

22. The device according to any of the claims 15 to 21, wherein the device is 
adapted to receive the user identity and a reference to the identity 
provider (ldP1 ) from a user device in response to a request for 
authentication sent from the device associated to the service provider 

1 0 (SP) to the user device. 

23. The device according to any of the claims 15 to 22, wherein the device is 
adapted to grant access to the service based on the assertion. 

15 24. The device according to any of the claims 20 to 22, wherein the device is 
adapted to grant access to the service based on the assertion and the 
check for acceptance. 

25. The device according to any of the claims 15 to 24, wherein the device is 
20 adapted to execute an authentication upgrade based on a further 

authentication based on a further authentication security profile. 

26. The device according to any of the claims 15 to 25, wherein the device is 
adapted to change for the authentication upgrade to a further identity 

25 provider (ldP2) for executing the further authentication. 

27. A device associated to an identity provider (ldP1), the device comprising 
a receiving unit for receiving messages, a transmitting unit for sending 
messages, and a processing unit for processing messages and 

30 information, wherein the device is adapted to 

- receive a request for an authentication of a user, the request 
comprising a user identity identifying the user to the identity 
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provider (ldP1) and an indication for one or more authentication 
security profiles specifying an authentication security requirement 
of the service provider (SP) for the authentication of the user to a 
service of the service provider (SP), 
5 - authenticate the user based on the user identity and one of the 

one or more authentication security profiles, and 
- send an assertion indicating to the service provider (SP) the 
authentication of the user. 



10 28. The device according to claim 27, wherein the device is adapted to 

authenticate the user based on at least one security attribute comprised 
in the one authentication security profile based on which the 
authentication is executed. 



15 29. The device according to claim 27 or 28, wherein the device is adapted to 
send an indication for a group of one or more security profiles that are 
supported for the authentication by the identity provider (ldP1) to the 
service provider (SP). 



20 30. The device according to any of the claims 27 to 29, wherein the device is 
adapted to select said one authentication security profile based on which 
the authentication is executed from the authentication security profiles. 



31 .The device according to any of the claims 27 to 30, wherein the one or 
25 more authentication security profiles are related by one or more relations 

to one or more further authentication security profiles, each relation 
expressing an ordering of the one or more authentication security profiles 
to the one or more further authentication security profiles regarding an 
authentication strength and wherein the device is adapted to execute the 
30 authentication of the user by selecting one of the one or more further 

authentication profiles being related equally strong or stronger regarding 
the authentication security strength compared to the one or more 
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authentication security profiles and by authenticating the user based on 
the selected further authentication security profile. 

32. The device according to claim 31, wherein the device is adapted to 

5 receive an indication for the one or more relations to the one or more 

further authentication security profiles from the service provider (SP). 

33. The device according to any of the claims 27 to 32, wherein the device is 
adapted to supplement the assertion with an indication of the 

10 authentication security profile based on which the authentication is 

executed. 

34. A device associated to an identity provider (ldP1), the device comprising 
a receiving unit for receiving messages, a transmitting unit for sending 

15 messages, and a processing unit for processing messages and 

information, wherein the device is adapted to 

- receive a request for an authentication of a user, the request 
comprising a user identity identifying the user to the identity 
provider (ldP1), 

20 - authenticate the user based on the user identity and an 

authentication security profile, and 

- send an assertion indicating to the service provider (SP) the 
authentication of the user, the assertion being supplemented by 
an indication of the authentication security profile based on which 

25 the authentication of the user is executed. 

35. The device according to any of the claims 27 to 34, wherein the device is 
adapted to execute an authentication upgrade, the authentication 
upgrade being based on a further authentication based on a further 

30 authentication security profile. 
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36. A computer program loadable into a device associated to a service 
provider (SP), the computer program comprising code adapted to 
execute any of the steps of the method according to any of the claims 1 
to 14 as far as related to the service provider (SP). 

5 

37. A computer program loadable into a device associated to an identity 
provider (ldP1), the computer program comprising code adapted to 
execute any of the steps of the method according to any of the claims 1 
to 14 as far as related to the identity provider (ldP1). 
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